1. Field of the Invention
The present invention relates to the field of application fault handling and more particularly to core dump file generation during application fault handling.
2. Description of the Related Art
The development and deployment of a computer program generally follows an academically defined software lifecycle. The development of an application begins with the design and functional specification of the application followed by both internal and external testing. Once testing has proven the efficacy of the application, the application can be deployed to the end user for use in the field. Subsequently, as run-time and logical errors are discovered in the application, revisions to the application can be designed, tested and deployed. Eventually, a new version of the application can be deployed replacing the originally deployed application and the lifecycle can begin anew.
Run-time errors and logical errors differ from one another. A logical error refers to program code that operates as programmed, but outside of the intent of the programmer. Logical errors oftentimes arise during the functional specification of the application, though on occasion the programmer can interject a run-time error during coding contrary to the functional specification. A run-time error, by comparison, refers to program code that disrupts the operation of the application when executed. Though fault handling has been incorporated into many modern programming languages, in many cases, a run-time error results in the cessation of execution of the operation—commonly referred to as an application fault or a “crash”.
Determining the root cause of an application fault can be challenging for the software developer. In many cases, the application fault will have arisen from a multitude of environmental factors coupled with programmatic errors resulting in the perfect storm—the crash. Reproducing the application fault in order to diagnose the cause, in consequence, can be difficult without the developer knowing a priori the contributing environmental factors. To assist the developer in addressing an application fault, sophisticated operating environments provide for the generation of diagnostic artifacts in response to detecting an application fault. Though reminiscent of the venerable “Dr. Watson”, in truth, core dumping routines have been in wide use decades prior to the advent of the personal computer.
Core dumping of diagnostic artifacts have been part and parcel of virtualized computing environments such as the Java™ computing environment since such environments gained wide popularity more than a decade ago. (Java is a registered trademark of Sun Microsystems, Inc. of Palo Alto, Calif., United States of America) At present, in the event of detecting an application fault requiring termination of execution of an application, the Java environment provides an interrupt signal to be intercepted by a virtual machine signal handler. Upon interception of the interrupt signal, the handler can generate a core dump or a heap dump, depending upon the configuration of the virtual machine. Thereafter, the core dump or heap dump can be passed to the operating system in which the dump can be placed in file form in the file system as a native “core file”.
A core dump generally includes summary information relating to the threads of the faulted application as well as the application state itself. A heap dump, by comparison, includes the content of the application heap at the time of the application fault. For many applications, the generation of a core dump is of no concern as the primary goal remains to diagnose the root cause of the fault. Yet, in certain deployment environments, the ability for an un-trusted third party to view the content of the core dump can result in a breach of privacy. In particular, within certain industries such as the healthcare and financial services industries, this type of breach of privacy can be problematic both practically and legally.